Component relationships when using generic JMS
The relationships are not as complex when using JMS to send and receive messages within your application code. This is much more dependent on how you code your application.
As was discussed in Basic workload patterns for Web and EJB container workloads, doing generic JMS calls means using QueueConnections and QueueSessions, whether it is work with publish and subscribe or point-to-point.
As was mentioned earlier, QueueConnection objects are thread safe so they can be cached and then used across multiple threads in the application. However, QueueSessions are not thread safe so each thread will need its own QueueSession.
These diagrams represent a single point in time. For example, in your application thread it could be using more than one QueueSession, but it would only be using one QueueSession at a time. These diagrams represent two extremes of using JMS objects. There are variations in between, for example the QueueConnection could be cached at a lower level than across the whole application, doing this would again affect the relationship between the JMS components and the application.
Figure 15-7 JMS component relationships when caching QueueConnection
JMS component relationships when not caching the QueueConnections
To understand how the JMS components are related requires an understanding of how the application is using those components. Unlike when using the message listener service, it is the application design or development that will define how these are used and therefore what the relationship is between the components.
For a QCF or TCF, configuring the number of QueueConnections in the connection pool, and QueueSessions in the session pool ultimately relies on knowing the way in which the code is written.
Caching QueueConnections means that more QueueSessions are needed in the session pool.
Example 1
There are 30 application threads all needing to simultaneously place a message on a Queue through the same QCF. One QueueConnection is obtained and shared across the threads. This then means that 30 QueueSessions are needed from that one QueueConnection. Connection pool maximum only needs to be 1 in this example, session pool maximum size needs to be 30.
Using a new QueueConnection for each thread means that there will probably be a 1 to 1 relationship between the QueueConnection and QueueSession used on that thread, so there will need to be more QueueConnections in the connection pool and less QueueSessions.
Example 2
There are 30 application threads all needing to place a message on a Queue through the same QCF simultaneously. Each thread obtains a QueueConnection and from that a QueueSession. This means that 30 QueueConnections are needed and only one QueueSession per connection. Connection pool max would need to be 30 but the session pool maximum would only need to be 1.
These are two extreme scenarios and the values in the examples do not take into account any other part of the application.
WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.
IBM is a trademark of the IBM Corporation in the United States, other countries, or both.